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PROCEDE ET DISPOSITIF DE CONTROLS DU CYCLE 
DE VIE D'UN OBJET PORTATIF, NOTAMMEHT D'DNE 

CARTE A PUCE 



L ' invention conceme les objets electroniques portatifs 
te l 8 que les cartes » microcircuits electroniques. Site, 
cartes a puce qui. connects a des disposers 
^ectroniques pour permettre a ces demiers de realiser des 
fictions particulieres dans le cadre d'une ou plus.eurs 
applications, necessitent un controle de leurs etapes de 
^ xlsdites cartes sent en effet gen.rale.ent utiles 
dans des applications (banque, communication, identite, 
sante...) nfessitant une grande Neurit* centre les usages 
™ieuK. L 1 invention S . applique plus generalement a tout 
systeme embarque independant. dote d'une unite de 
traitement et des memoires de programme et de dormees. 

H est connu dans le monde de la carte a puce que 
celle-ci resulte d'un assemblage d'un composant (comprenant 
H general un microprocesseur en relation avec des metres 
v ia des bus de convocation, . d'un module • 
i.aide d'un meta! conducted) auquel est relie ledit 
composant (dans le cadre d.une carte a puce dite - «»^ 
pour permettre audit conusant d'etre connecte a un 
disposLif electronique de lecture et/ou ecriture ou 
^eur, et d'un corps de carte ou plus generalement d'un 
support sur lequel est integre !• ensemble module/composant 
Dans la cadre d'une carte a puce dite sans contact, ledit 
Tdule est remplace par une antenne et ensemble forme par 
le composant et ladite antenne est integre au sein dudit 

"^vie d'une carte a puce se decompose generalement en 
d eux ensembles drapes se succedant les unes au. autres 
correspondant respect ivement a la fabrication et a 
Sexploitation de ladite carte. La composition des deux 
enseLles *■ etapes forme un cycle de vie de ladite carte. 



La fabrication d'une carte a puce (a contact ou sans 
contact) est constitute de plusieurs etapes. 

En effet, il est tout d'abord necessaire de disposer 
d'un composant electronique qui est initialise, isole, puis 
relie a un module. Ledit composant et le module, auquel il 
est relie, sont par la suite integres sur ou au sein d'un 
support (generalement un corps de carte plastique) lui meme 
imprime a des fins d' identification ou de publicite. Par la 
suite la carte a puce ainsi obtenue est initialisee ou 
programmee pour repondre aux conditions d' utilisation dans 
le cadre d' applications . 

Le second ensemble d' etapes de vie d'une carte a puce 
correspond a son exploitation. Cet ensemble peut lui -meme 
gtre divise en plusieurs etapes, chacune correspondant , par 
exemple, a 1 • implantation ou la suppression de services 
offerts par la carte a puce a 1 ' utilisateur en fonction de 
son profil par exemple. 

En outre differents acteurs (fabricant de composant, 
fabricant de cartes a puce, centre de personnalisation de 
cartes, emetteur de cartes, ou encore porteur de cartes) 
interviennent durant les differentes etapes de la 
fabrication et de 1 ' exploitation d'une carte a puce. Ainsi, 
les composants sont fournis et parfois en partie 
initialises par des fabricants de composants electroniques 
sur une tranche de silicium. Cette phase correspond a 
l'etape de fabrication du composant . L'etape suivante est 
la phase d'encartage realisee par le fabricant de carte a 
puce. Elle inclut l'isolement d'un composant de la tranche 
de silicium, la connexion dudit composant a un module (ou 
antenne), 1 ' integration de 1' ensemble sur leur support ou 
corps de carte. Suit la preparation de la structure 
applicative presente dans la memoire programmable 
electriquement du composant. C'est l'etape de 
personnalisation electrique qui est realisee par le 
fabricant des cartes a puce ou par un centre de 
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personnalisation ou un tiers specialise 1 dans la 
personnalisation des cartes ou par l'emetteur lui-m§me qui 
est charge 1 in fine de la distribution des cartes sur le 
marche\ Cette phase de personnalisation electrique peut 
5 done §tre decomposed en autant d' Stapes qu'il y a acteurs 
ou d' intermediates. Par la suite, durant 1 • exploitation de 
la carte a puce, nous avons vu precSdemment qu'il peut etre 
interessant de distinguer differentes etapes au gre de 
1' evolution du profil de 1 'utilisateur de la carte par 
10 exemple. 

Quoi qu'il en soit, il est done important de suivre 
rigoureusement les etapes de vie d'une carte pour connaltre 
a tout moment l'etape en-cours de ladite carte au sein de 
son cycle de vie. De plus, il est indispensable que, d'une 

15 part, l'acces en ecriture ou en lecture de la memoire 
programmable Slectriquement du composant d'une carte soit 
protege durant l'Schange de ladite carte (ou du composant) 
entre les differents acteurs et que d' autre part l'acces a 
ladite memoire soit limite au fur et a mesure que se 

20 succedent les Stapes de vie de la carte citees 
precedemment, en activant ou desactivant des services par 
exemple. Pour finir, il est egalement necessaire parfois de 
valider le contexte applicatif de la carte a puce avant que 
le porteur de celle-ci 1 'utilise sur le marche. Par 

25 exemple, un emetteur de carte a puce de type porte-monnaie 
electronique, doit etre certain que la balance de ladite 
carte est bien nulle avant d'emettre la carte. 
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Pour tenter de repondre a ces exigences, differentes 
solutions sont utilisees a ce jour. Certaines solutions 
sont purement exterieures a la carte a puce (securisation 
physique des locaux ou ladite carte est fabriquee, 
utilisation de moyens de transport eux-memes sScurisSs . . . ) . 
D'autres solutions complementaires aux premieres, mais 
cette fois internes ou implantees dans la carte, sont aussi 
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general ement utilisees. On utilise ainsi des secrets 
permettant de proteger 1 1 acces en lecture/6criture de la 
memoire du composant et egalement des indicateurs logiques 
permettant de suivre de maniere irreversible les 
5 differentes etapes de vie de la carte. Pour cela, des bits 
au sein d'une memoire non eff arable du composant de la 
carte a puce sont positionnes a 1 ' etat actif a la fin des 
differentes etapes de vie de la carte (fabrication et 
initialisation du composant par le fabricant dudit 
10 composant, encartage et initialisation de la memoire de la 
carte par le fabricant de carte a puce, preparation de la 
structure applicative de la memoire de la carte a puce par 
le centre de personnalisation ou l'emetteur de la 
carte...). En fonction de ces indicateurs, le programme (ou 
15 systeme d» exploitation) , execute par le microprocesseur du 
composant de la carte a puce, implante au sein de l'une des 
memoires dudit composant de ladite carte, adapte son 
comportement au fur et a mesure que les etapes de vie de 
ladite carte se succedent . Ainsi, des fonctions peuvent 
20 etre modifiees, ajoutees ou supprimees . 

Quelles que soient les solutions utilisees a ce jour, 
elles reposent toutes sur le fait que les differents 
acteurs impliques dans la fabrication d'une carte sont des 
25 tiers de confiance. Seules des personnes, susceptibles 
d' intercepter des composants ou des cartes durant leur 
transfert entre deux des differents acteurs, sont supposees 
"fraudeurs potentiels" et l^s solutions exposees 
precedemment permettent de s 1 en affranchir. L' adaptation du 

30 systeme d« exploitation de la carte en fonction des 
indicateurs irr^versibles apporte un plus non negligeable. 
Ainsi, si les fabricants de composants ou de cartes 
inscrivent des donnees systemes ou des secrets, l'emetteur 
de la carte ne pourra par exemple librement s' affranchir 

35 desdits secrets ou modifier lesdites donnees systeme. 
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61ectronique portatif en fonction de la transition d' etats 
a effectuer; 

- les moyens de controle comprennent des moyens 
d' autorisation / interdiction des transitions d'etat; 

- les moyens de controle comprennent : 

- une table des transitions d'etat possibles; 

- une table des verifications a effectuer par 

transition d'etat possible; 

- un raoteur de verification exploitant lesdites 

tables ; 

- les moyens de controle comprennent des moyens 
permettant de declencher des actions lors du traitement 
d'une demande de f ranchissement d'une transition d'etat; 

- des actions, dites actions systematiques , sont 
declenchees lors du f ranchissement d'une transition d'etat 
ou du re jet du f ranchissement de ladite transition; 

- des actions, dites actions positives, sont 
declenchees lors du f ranchissement d'une transition d'etat; 

- des actions, dites actions negatives, sont 
declenchees lors du re jet du f ranchissement d'une 

transition d'etat; 

- les moyens permettant de declencher des actions, 
comprennent une table d' actions exploitable par le moteur 
de verification; 

- des etats supplementaires (dits etats additifs) 
peuvent etre ajoutes au sein de la memoire de donnees ; 

- les moyens de contr61e de la transition d'etat 
comprennent en outre au moins une extension de la table des 
transitions et au moins une extension de la table des 
verifications, lesdites extensions de tables etant 
exploitables par le moteur de verification; 

- les moyens de controle de la transition d'etat 
comprennent en outre au moins une extension de la table des 
actions, ladite extension de table etant exploitable par le 
moteur de verification; 
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- la demande de transition peut etre generSe par une 
action declenchee lors du f ranchissement ou du re jet de 
f ranchissement d'une transition; 

5 En outre, 1 1 invention concerne un procede destine a 

etre exploite par un dispositif de controle du cycle de vie 
d'un objet elect ronique portatif comprenant une unite de 
traitement, une mSmoire volatile, des memoires de 
programmes et des memoires de donnees, le contenu desdites 

10 memoires definissant une pluralite d 1 etats qui 
correspondent respect ivement a une configuration donnee de 
1 ■ ob j et , chacun desdits Stats determinant les services 
offerts par ledit objet, caracterise en que ledit procede 
comprend une pluralite d'etapes, lesdites etapes Stant 

15 dSpendantes du type des etats impliques dans la demande de 
f ranchissement d'etat appliquSe a I'objet, le premier type 
d'Stat correspondant aux etats prSdefinis dits "etats de 
reference" et le second type d'etat correspondant aux 6tats 
pouvant etre ajoutes dits "etats additif s" . 

20 Selon d'autres caracteristiques du procede, dans le cas 

ou la demande de f ranchissement de transition appliquee a 
1' objet est une demande de f ranchissement de transition 
d 1 un etat de reference vers un autre Stat de reference , 
ledit procede comprend : 

25 - une Stape de validation de 1 1 autorisation de ladite 

demande en analysant la table des transitions possibles ; 

- une etape devaluation des verifications associees a 
la t r ans i t i on demande e en ana ly s ant la t abl e de s 
verifications ; 

3 0 - une etape de modification de 1 1 etat courant de 

I 1 objet si et seulement si : 

- la transition demandee est autorisee 

- et, si les verifications de la configuration de 
1 1 obj et sont satisf aites ; 
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- une etape d* execution d' actions systematiques en 
analysant l 1 entree de la table d 1 actions correspondant a la 
transition demandee; 

- une etape d' execution d 1 actions positives en 
analysant 1 1 entree de la table d' actions correspondant a la 
transition demandee si la transition demandee est autorisee 
et si les verifications associ£es a la transition demandee 
sont satisfaites; 

- une etape d 1 execution d 1 actions negatives en 
analysant 1' entree de la table d' actions correspondant a la 
transition demandee si les verifications associees a la 
transition demandee ne sont pas satisfaites. 

Selon d'autres caracteristiques du procede, dans le cas 
ou la demande de f ranchissement de transition appliquee a 
l'objet est une demande de f ranchissement de transition 
d'un £tat additif vers un autre etat additif, ledit procede 
comprend : 

- une 6tape de validation de 1 ' autorisation de ladite 
demande en analysant une extension de la table des 
transitions possibles; 

- une etape devaluation des verifications associee a 
la transition demandee en analysant une extension de la 
table des verifications; 

- une etape de modification de 1 ' etat courant de 
l'objet si et seulement si : 

- la transition demandee est autorisee 

- et, si les verifications de la configuration de 
l'objet sont satisfaites; 

- une etape d' execution d 1 actions systematiques en 
analysant 1 1 entree d'une extension de la table d 1 actions 
correspondant a la transition demandee; 

- une etape d 1 execution d 1 actions positives en 
analysant 1 1 entree d'une extension de la table d 1 actions 
correspondant a la transition demandee si la transition 
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demandee est autorisee et si les verifications associees a 
la transition demandee sont satisfaites; 

- une etape d 1 execution d 1 actions negatives en 
analysant 1 'entree d'une extension de la table d' actions 
5 correspondant a la transition demandee si les verifications 
associees a la transition demandee ne sont pas satisfaites. 



Selon d'autres caract§ristiques du procede, dans le cas 
ou la demande de f ranchis semen t de transition appliquee a 
10 l f objet est une demande de f ranchissement de transition 
d'un etat de reference vers un etat additif, ledit procede 
comprend : 

- une etape de validation de 1 1 autorisation d'une 
transition dudit etat de r6f£rence vers un etat additif en 

15 analysant la table des transitions possibles; 

- une etape de validation de 1 1 autorisation de la 
transition dudit etat de reference vers ledit 6tat additif 
en analysant une extension de la table des transitions 
possibles; 

2 0 - une etape devaluation des verifications associee a 

la transition demandee en analysant une extension de la 
table des verifications; 

- une etape de modification de 1 1 etat courant de 
l'objet si et seulement si : 

25 - la transition demandee est autorisee 

- et # si les verifications de la configuration de 
l'objet sont satisfaites; 

- une etape d' execution d 1 actions systematiques en 
analysant 1 ' entree d ■ une extension de la table d ■ actions 

30 correspondant a la transition demandee; 

- une etape d 1 execution d'actions positives en 
analysant l'entree d'une extension de la table d 1 actions 
correspondant a la transition demandee si la transition 
demandee est autorisee et si les verifications associees a 

35 la transition demandee sont satisfaites; 
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- une etape d' execution d* actions negatives en 
analysant 1 ' entree d'une extension de la table d* actions 
correspondant a la transition demandee si les verifications 
associees a la transition demandee ne sont pas satisfaites. 

5 

Selon d'autres caracteristiques du proc^de, dans le cas 
ou la demande de f ranchissement de transition appliquee a 
l'objet est une demande de f ranchissement de transition 
d'un etat additif vers un etat de reference, ledit procSde 
10 rejette ladite demande. 

L ' invention concerne egalement un objet electronique 
portatif, comportant une unite de traitement, une memoire 
volatile, des memoires de programmes et des memoires de 

15 donnees, caracterise en ce qu'il comporte ledit dispositif 
de contr61e du cycle de vie de l'objet. 

En outre, 1' invention concerne une carte a puce, 
comportant une unite de trait ement, une memoire volatile, 
des memoires de programmes et des memoires de donnees, 

20 caracterise en ce qu'elle comporte ledit dispositif de 
contr61e du cycle de vie de la carte. 

L 1 invention sera mieux comprise a la lecture de la 
description qui suit et a 1 ' examen des figures qui 
25 1 ' accompagnent . Celles-ci ne sont donnees qu'a titre 
indicatif et nullement limit at if de 1' invention. Les 

figures montrent: 

- figure 1: un composant d'une carte a puce rnunie d'un 
dispositif de verification de transition d'etat; 

30 - figures 2a et 2b: une representation detaillee d'une 

table des transitions d'§tat; 

- figure 3: une representation detaillee d'une table 
des verifications des transitions; 

- figure 4: une representation detaillee d'une table 

35 des actions; 
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- figure 5: une description des etapes mises en ouvre 
dans le procede utilise par le dispositif de verification 
de transitions; 

- figures 6a a 6d: les particularity mises en oeuvre 
5 dans le cas d'un exemple d'une carte a puce de type porte- 

monnaie electronique; 

Dans 1' invention, on appellera etat de reference, un 
etat a partir duquel il est possible de basculer vers un 
autre etat suite au f ranchissement d'une transition decrite 
10 dans la table des transitions, implantee dans la memoire de 
programme. Comme il est decrit plus loin, il est possible 
d'aj outer de nouveaux etats et done de nouvelles 
transitions apres que l'etape de fabrication du composant 
ait eu lieu. Dans ce cas, on parlera d'Stats additifs pour 
15 caracteriser ceux-ci par opposition aux etats de reference. 
D' autre part, on appellera etat courant 1 ' etat dans lequel 
se trouve le systeme embarqu€. 

La figure 1 montre un composant 1, d'une carte a puce, 
muni d'un dispositif de verification de transitions selon 
2 0 1' invention. Le composant comporte une unitS de traitement 
2 ou encore microprocesseur en relation avec des memoires 
3, 4 et 5 via un bus de communication 6. Une memoire de 
programme 4 (ou encore ROM) non effacable comporte d'une 
part une zone de programmes 7, lesdits programmes (ou 
25 encore systeme d' exploitation du systeme embarque) pouvant 
etre executes par ladite unite de traitement et d' autre 
part une zone de donnees pre-definies 10 qui contient des 
constantes utilisees par ledit systeme d« exploitation. 
Parmi lesdites constantes de la zone 10, le systeme 
30 d' exploitation 7, comportant un programme appele moteur de 
verification 9, exploite une table des transitions 11 qui 
permet de preciser les etats auxquels on peut acceder a 
partir de 1 ' etat courant, une table des verifications 12 
qui permet d'associer a chaque transition d'etat des 
35 verifications portant sur le contenu des memoires 3, 4 



12 



et/ou 5. Dans une variante, le moteur de verification 9 
peut declencher automatiquement des actions lors du 
franchissement ou du rejet du f ranchissement d'une 
transition. Pour cela la zone 10 de la memoire de programme 
comporte une table des actions 13 qui permet d'associer a 
chaque transition d'etat possible des actions a effectuer. 

Une memoire volatile 3 (ou encore RAM pour Random 
Access Memory en langue anglaise) permet a 1 'unite - de 
traitement 2 de stocker de maniere temporaire des resultats 
ou encore des secrets issus de calculs decrits par les 
programmes implantes dans la memoire de programme 4. Le 
contenu de la memoire 3 est efface a chaque mise sous 
tension du composant 1 ou a chaque demande de remise a zero 
de celui-ci. 

Une memoire de donnees 5, effacable Slectriquement 
utilisant generalement la technologie EEPROM (pour 
Electrical Erasable Programmable Read Only Memory en langue 
anglaise) comporte une zone 14 contenant les donnees 
variables necessaires a 1" execution des programmes 7. Cette 
zone 14 comporte notamment une donnee 8 appelee "Etat 
courant" permettant de memoriser l'etat courant de l'objet 
electronique portatif . La memoire de donnees 5 comporte en 
outre une zone 15 comprenant optionnellement des extensions 
des tables 11 a 13 dans le cas ou il est necessaire 
d'ajouter des etats aux Stats de references. La zone 15 
comporte alors une extension de la table des transitions 
16, une extension de la table des verifications 17 et peut 
comporter une extension de la table des actions 18 si l'on 
souhaite associer aux nouvelles transitons d'etat additif 
des actions, comme vu precedemment pour ce qui concerne la 
table 13. Dans le cas d'ajout d' etats par rapport aux Stats 
de reference, il est parfois indispensable d'enrichir le 
systeme d' exploitation 7. Pour cela, la memoire 5 peut 
comporter en outre une zone 19 qui contient les programmes 
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supplementaires qui seront executes a leur tour par 1" unite 
de traitement 2 . 

La figure 2a montre une mise en ouvre possible de la 
table des transitions 11. Si l'on suppose que l'on dSnombre 
i etats de reference, on peut imaginer une table de 
transition comprenant i colonnes et i lignes. Les colonnes 
correspondent aux etats de reference pouvant etre, a un 
instant donne, l'etat courant. Les i premieres lignes 
correspondent aux etats de reference auxquels on peut 
acceder a partir de l'etat courant. Ainsi la valeur d'une 
case de la table des transitions 11 correspondant a 
1 ■ intersection d'une ligne et d'une colonne de ladite table 
permet de coder soit, 1' absence de transition autorisee 
(valeur nulle par exemple - c ' est le cas de la transition 
20), soit, 1 ' autorisation une transition (valeur non nulle 
- c'est le cas de la transition 21). Dans le cas d'une 
transition autorisee, le moteur de verification de 
transitions recherche au sein de la table de verification 
12 les verifications a effectuer pour accepter ou rejeter 
le franchissement de la transition demandee. 

La figure 2b montre egalement une mise en ouvre 
possible d'une table de transition dans le cas ou il est 
possible d'aj outer des etats (etats additifs) aux etats de 
reference. La table des transitions comporte une ligne 
supplemental par rapport a la figure 2a. La (i+l)eme 
ligne permet de preciser si l'on autorise des transitions 
d'un etat de reference courant a un etat additif. Ainsi la 
valeur de la case 22 indique une transition interdite d'un 
etat de reference vers un etat additif. La case 23 indique 
qu'il sera possible de basculer de l'etat de reference Ei 
vers un etat additif. Une extension 16 de la table des 
transitions est alors necessaire. Cette derniere comporte j 
lignes correspondant a j etats additifs auxquels on peut 
acceder a partir de (i+j) etats courant possibles 
materialises par les (i+j) colonnes de 1 'extension 16 de la 
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table des transitions. Ainsi la combinaison de la case 23 
de la table des transitions et de la case 24 de 1 • extension 
16 de la table des transitions, indique au moteur de 
verification qu'il est possible de basculer de l'etat de 
reference Ei vers l'etat additif E(i+1) . 

La figure 3 montre une mise en ouvre de la table des 
verifications. La table des verifications 12 est implantee 
au sein de la zone 10 des donnees pre-definies de la 
memoire 4. Chaque transition autorisee dispose d'une entree 
dans ladite table. Une entree comprend un champ 30 
pertnettant d' identifier la transition et un champ 31 
contenant une reference (ou adresse) vers un programme 32 
du systeme d' exploitation 7. Le moteur de verification 9 
peut ainsi faire executer a 1 'unite de traitement 2 les 
controles requis pour accepter le f ranchissement de la 
transition. La figure 3 illustre egalement une structure 
d'une extension 17 de la table des verifications. De la 
meme maniere que pour la table 12, 1' extension de la table 
des verifications 17 comporte une entree par transition 
possible. Chaque entree comprend deux champs, un champ 33 
pertnettant d' identifier la transition et un champ 34 
contenant une reference (ou adresse) d'un programme 35 du 
systeme d' exploitation ou, comme le montre la figure 3, 
d'un programme supplementaire implante dans la memoire de 
donnees 5 (en zone 19) . 

La figure 4 montre une representation de la table des 
actions 13 implantee dans la zone 10 des donnees pre- 
definies de la memoire de programmes 4. Lors d'une demande 
de franchissement de transition, il est possible de 
declencher des actions. Celles-ci peuvent §tre de trois 
types: action systematique, action positive (c'est a dire 
conditionnee au fait que les verifications sont 
satisfaisantes) ou action negative (c'est a dire 
conditionnee au fait que les verifications ne sont pas 
satisfaisantes). La figure 4 montre qu'a chaque transition 
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autorisee, il existe une entree dans la table des actions 
13. Cette entree comprend 4 champs. Le premier champ 400 
permet d' identifier la transition. Les trois autres champs 
401, 402 et 403 contiennent chacun une reference ou adresse 
d'un programme 404, 405 ou 406 du systeme d' exploitation. 
Le champ 401 est dedie & une action systematique, le champ 
402 a une action positive et le champ 403 & une action 
negative. La figure 4 montre egalement une extension 18 de 
la table des actions. Cette table 18 est implantee dans la 
zone 15 de la memoire de donnees 5 du composant 1. De la 
meme maniere que pour la table des actions 13, 1 • extension 
de la table des actions 18 comprend une entree par 
transition possible. Une entree comprend 4 champs. Le 
premier champ 407 permet d' identifier la transition. Les 
15 trois autres champs 408, 409 et 410 contiennent chacun une 
reference ou adresse d'un programme 411, 412 ou 413 du 
systeme d' exploitation ou comme le montre la figure 4, des 
programmes implantes dans la zone 19 de la memoire de 
donnees 5 du composant 1. Le champ 408 est dedie & une 
action systematique, le champ 409 a une action positive et 
le champ 410 & une action negative. 

La figure 5a decrit le procede permettant de valider ou 
de rejeter le f ranchissement d'une transition d'etat, d'un 
premier etat de reference vers un autre etat de reference. 
La demande de f ranchissement d'une transition peut etre 
formulee suite a un ordre du fabricant de carte ou par tout 
autre acteur du cycle de vie de la carte a puce. Ladite 
demande peut egalement etre formulee directement par la 
carte-elle meme, par exemple au travers d'une action 
associee a une transition. Dans le cadre de la figure 5a, 
l'gtat de reference courant est l'etat Ei. L' ordre 50 de 
basculement de l'etat Ei a l'etat Ej est formule. L'etape 
51 consiste a verifier au sein de la table des transitions 
11 que la transition de l'etat Ei vers l'etat Ej est 
autorisee. Dans le cas ou cette transition est interdite, 
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la demande de f ranchissement de transition 50 est rejetee. 
L'etat ( courant demeure l'etat Ei. Par contre, si la 
transition est autorisee, le moteur de verification 9 
execute les verifications associees a ladite transition. 
5 Pour cela le moteur de verification evalue 1 ' entree de la 
table des verifications 12 dediee a la transition T(Ei- 
>Ej). L 1 execution desdites verifications correspond a 
l'etape 52 du procede. Le moteur de verification 9 execute 
les actions systematiques associees a la transition T(Ei- 
10 >Ej) en fonction de 1- entree de la table des actions 13 
dediees a ladite transition (etape 53) . Si les 
verifications 54 exigees lors de la demande de 
f ranchissement de la transition 50 sent non satisf aisantes, 
l'etat courant demeure inchange. En fonction de 1 ' entree de 
la table des actions 13 associee a la transition T(Ei->Ej) 
le moteur de verifications execute les actions negatives 
(etape 55 du procede) . Le deroulement du procede est alors 
termine. Par contre, si les verifications 54 sont 
satisf aisante, alors l'etat courant devient l'etat Ej 
(etape 56 du procede) . Les actions positives sont alors 
executees (etape 57 du procede) en fonction de l'etat de 
1- entree de la table des actions 13 associee a la 
transition T (Ei->Ej ) . Le deroulement du procede est 
termine . 

La figure 5b decrit le procede permettant de valider ou 
de rejeter le f ranchissement d'une transition d'etat, d'un 
premier etat additif vers un autre etat additif. L'etat 
additif courant est l'etat Ei . L'ordre 510 de basculer de 
l'etat additif Ei a l'etat additif (ou de reference) Ej est 
formule. L'etape 511 du procede consiste a verifier au 
sein de 1' extension la table des transitions 16 que la 
transition de l'etat Ei a l'etat Ej est autorisee. Dans le 
cas ou cette transition est interdite, la demande de 
f ranchissement de transition 510 est rejetee. L'etat 
courant demeure l'etat Ei . Par contre, si la transition est 
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autorisee, le moteur de verification 9 execute les 
verifications associees a ladite transition. Pour cela, le 
moteur de verification evalue l 1 entree de 1' extension de la 
table des verifications 17 d^diee a la transition T (Ei- 
>Ej). L 1 execution desdites verifications constitue 1' etape 
512 du procede. Le moteur de verification 9 execute les 
actions systematiques associees a la transition T(Ei->Ej) 
en fonction de 1' entree de 1' extension de la table des 
actions 18 dediees a ladite transition (etape 513 du 
procede) . Si la verification 514 exigee lors de la demande 
de franchissement de la transition 510 est non 
satisf aisante, 1 1 etat courant demeure inchange. En fonction 
de 1' entree de 1 1 extension de la table des actions 18 
associee a la transition T(Ei->Ej) / le moteur de 
verification 9 execute les actions negatives (etape 515 du 
procede) . Le deroulement du procede est alors terming. Par 
contre, si les verifications 514 sont satisf aisantes , 
l'etat courant devient l'etat Ej (etape 516 du proced£) . 
Les actions positives sont alors executees (etape 517 du 
procede) en fonction de l'etat de 1» entree de 1' extension 
de la table des actions 18 associee a la transition T (Ei- 
>Ej) . Le deroulement du procede est termine. 

La figure 5c decrit le procede permettant de valider ou 
de rejeter le franchissement d'une transition d'etat, d'un 
etat de reference vers un etat additif . L ! etat de reference 
courant est l'etat Ei . L'ordre 520 de basculement de l'etat 
de reference Ei a l'etat additif Ej est formuie. L ! etape 
52 8 du procede consiste a verifier au sein de la table des 
transitions 11, qu'une transition de l'etat de reference 
courant Ei vers un etat additif est autorisee. Si une telle 
transition est interdite, le procede est termine. L'etat 
courant demeure inchange. Par contre, si une transition 
dudit etat de reference vers un etat additif est autorisee, 
le moteur de verification deroule les etapes 521 a 527 du 
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procede, respect ivement identiques aux etapes 511 a 517 
decrites en liaison avec la figure 5b. 

Un exemple d' application dans le domaine du Porte- 
monnaie electronique est presente en liaison avec les 
figures 6a a 6d. Ladite application permet de regler des 
achats k l'aide "d' argent electronique" stocke dans une 
carte a puce, au lieu de payer en numeraire. L'emploi d'une 
telle technique impose une gestion des cartes aussi 
securisee que celle qu'aurait impose l'emploi du numeraire. 
II faut par exemple eviter la creation de monnaie fictive. 
La securite d'une carte a puce porte-monnaie Electronique 
repose generalement sur des cles stockees a l'interieur de 
ladite carte a puce permettant des transactions securisees 
en utilisant la cryptographie . Une telle carte dispose d'un 
systeme d' exploitation off rant un jeu de commandes et de 
services permettant de crediter ou de debiter de 1' argent. 
Au debut du cycle de vie de la carte a puce porte-monnaie 
electronique, ladite carte a puce n'est pas initialisee. 
Elle ne contient aucune information. La figure 6a montre 
les etats de reference pre-definis : 

- Etat El "carte vierge" (reference 80) : seules des 
commandes de test permettant de valider le comport ement de 
la memoire de donnees 5 sont disponibles (verification que 
les cases memoires de technologie EEPROM peuvent Stre 
correctement ecrites et ef facees) ; 

Etat E2 "carte testee" (rSf^rence 82) : Les commandes 
de test ne sont plus disponibles. A leur tour des commandes 
dites generalement "commandes physiques" (permettant un 
acces en ecriture par un adressage physique independamment 
de toute structure logique de type fichier par exemple) 
sont disponibles. Elles permettent d' initialiser la carte 
(ecriture dans la zone 14 de la memoire de donnees des 
constituants logiques necessaires au f onctionnement de 
1 'application c ' est a dire fichiers, balances...); 



- Etat E3 "carte initialisee" (reference 84) : les 
commandes physiques ne sont plus disponibles . Des commandes 
logiques permettent de personnaliser la carte (ajout de 
nouvelles structures logiques et initialisation de donnees 
dans lesdites structures) sont utilisables. En outre, un 
mecanisme de recouvrement est activ6 de sorte que la carte 
a puce ne perde pas la coherence de ces donnees lors d ! une 
mise hors tension de celle-ci durant 1" execution de 1'une 
desdites commandes logiques. 

- Etat E4 "carte personnalisee" (reference 86) : les 
commandes logiques specif iques a 1 ' application Porte- 
monnaie electronique (d^bit/credit) sont activees. 

Le jeu de commandes disponibles evolue en fonction de 
l'etape de vie dans laquelle se trouve la carte a puce. Des 
informations stockees en memoire de donnees permettent au 
systeme d' exploitation de connaitre l'etat dans lequel la 
carte a puce se trouve . La figure 6a montre en outre que 
dans le cadre d 1 une carte de type porte -monnaie 
Electronique, toutes les transitions entre etats de 
reference doivent etre franchies successivement (de 1 1 etat 
El a l'etat E4) et ce de maniere irreversible. Toute autre 
transition est interdite. Seule la possibility d 'utiliser 
ulterieurement des etats additifs 88 est offerte. Cette 
transition possible est refSrencee 87 . Le systeme 
d' exploitation en fonction de l'etat courant n'autorise 
qu'un ensemble de commandes specif iques a chaque etat de 
reference . 

Les verifications et les actions a declencher lors du 
f ranchissement d'une transition sont d^crites comme suit : 
- Transition de l'etat El vers l'etat E2 (notee 
T(E1->E2) et ref^rencee 81) : 

- Verification : aucune 

- Action systematique : 

ef facement de la memoire de donnees pour 
eviter qu'un fraudeur y laisse des donnees 
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interprStables par le systeme 

d' exploitation de la carte; 
- Transition de l'etat E2 vers l'etat E3 (notee 
T(E2->E3) et r^ferencee 83) : 

- Verification: 

- int£grite des donnees Writes dans la 
memo ire de donnees avec les commandes 
physiques (validation d'un code de 
redondance par donn^e) ; 

- verification de l'etat vierge de la 
memoire en dehors desdites donnees; 

- Action positive : 

_ activation du m§canisme de recouvrement ; 

- Transition de l'etat E3 vers l'etat E4 (notee 
15 T(E3->E4) et refSrencee 85) : 

- Verification: 

- nullity de la balance du porte monnaie 

electronique 

- Action : aucune 

- Transition de l'etat E4 vers un 6tat additif (notee 
T(E4->Eadd) et r6f6rencee 87) : 

- Verification : aucune 

- Action : aucune 
Les figures 6b a 6d illustrent respect ivement une 

realisation d'une table des transitions 11, d'une table des 
verifications 12 et d'une table d' actions 13, selon 
1' invention. La table des transitions 11 telle que decrite 
en liaison avec la figure 6b permet de n'autoriser que les 
transitions 81, 83, 85 et 87. Pour cela seules les cases 60 
a 63 de ladite table contiennent une valeur non nulle. Les 
autres cases de la table des transitions contiennent une 
valeur nulle pour indiquer que toute autre transition est 
interdite. La table des verifications telle que presentee 
au travers de la figure 6c, permet d'associer les 
35 verifications a satisfaire pour autoriser le f ranchissement 
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des transitions 81, 83, 85 et 87, lesdites transitions 
autorisees par la table des transitions 11 (figure 6b) . 
Ainsi 1' entree 64 de la table des verifications 12 comporte 
un champ 641 permettant d ! identifier que ladite entree est 
dediee a la transition 81. L ' entree 64 comporte en outre un 
champ 642 contenant une reference nulle pour indiquer 
qu'aucune verification n'est demandee pour autoriser le 
franchissement de la transition 81. Dans une variante, la 
transition 81 ne dispose d'aucune entree associee. Cette 
variante est illustree plus loin dans le cas de la table 
des actions. La table des verifications 12 comporte une 
entree 65 qui comprend respect ivement un champ 651 pour 
indiquer que 1 ' entree est associee a la transition 83 et un 
champ 652 contenant la reference d'un programme 67, 
15 implante dans la memoire de programmes, pour que le moteur 
de verification puisse effectuer les verifications decrites 
precedemment. De meme, la table des verifications 12 
comporte une entree 66 qui comprend respect ivement un champ 
661 pour indiquer que 1' entree est associee a la transition 
83 et un champ 662 contenant la reference d'un programme 
68, implante dans la memoire de programmes, pour que le 
moteur de verification puisse effectuer les verifications 
decrites precedemment. 

La figure 6d presente une realisation de la table des 
actions 13. Ladite table comporte une entree 71 qui 
comporte un champ 711 permettant d' indiquer que ladite 
entree est associee a la transition 81. La meme entree 71 
comporte un champ 712 contenant la reference d'un programme 
75, implante dans la memoire de programmes, afin que le 
30 moteur de verification puisse executer les actions 
systematiques associees a la transition 81*. L 1 entree 71 
comporte en outre un champ 713 et un champ 714 contenant 
une reference nulle pour indiquer au moteur de verification 
qu'aucune action positive ni negative n'est associee au 
35 franchissement de la transition 81. De la meme maniere, la 
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table des actions 13 comporte une seconde entree 72 
comprenant les champs 721 a 724 pour indiquer au raoteur de 
verification que ladite entree est associ£e a la transition 
83, que le programme 74 est a executer comme action 
5 positive lors du f ranchissement de ladite transition et 
qu'aucune action systematique ou negative n'est a executer. 
Li 'absence d' entree, au sein de la table des actions 13, 
associee a la transition 85, indique qu'aucune action 
(systematique, positive ou negative) n'est a executer lors 
10 du f ranchissement ou du rejet du f ranchissement de ladite 
transition. 

Grace au dispositif et au proc£de tels que d£crits ci- 
dessus, le cycle de vie d'un objet glectronique portatif 
est maitrise\ Chaque transition d'etats est irreversible et 

15 les verifications faites lors de chaque demande de 
transitions garantissent une configuration memoire de 
1' objet coherente. En outre les actions systematiques, 
positives ou negatives permettent d' adapter le comportement 
dudit objet. Enfin, dans le cas ou il est prevu d'autoriser 

20 une ou plusieurs transitions d'un ou plusieurs gtats de 
reference vers un etat additif, le cycle de vie de 1' objet 
peut §tre facilement enrichi, par exemple apres que 1' objet 
soit emis sur le marche, sans que le cycle de vie predefini 
(compost par une succession de transitions d'etat de 

25 reference vers un autre Stat de reference) puisse etre 
detourn^ . 

Tout risque de fraude durant 1 ' initialisation d'un 
objet €lectronique portatif ou d'erreur malencontreuse 
durant ladite initialisation est ecarte tout en conservant 
30 grande adaptability du controle du cycle de vie de 1 'objet. 
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leuille *vant rectificatltite 



REVEND X CAT X ONS 



1. Dispositif de controle du cycle de vie, destine a etre 
implant^ dans un objet electronique portatif comprenant une 
unite de traitement (2) , une m^moire volatile (3) , des 
memoires de programmes (4) et des memoires de donnees (5) , le 
contenu desdites memoires def inissant une pluralite d 1 etats 
qui correspondent respect ivement a une configuration donn^e 
de l 1 objet, chacun desdits etats determinant les services 
offerts par ledit objet, caracterise en ce qu'il comporte des 
moyens de contr61e de la transition d'un etat a un autre etat 
de 1' objet electronique portatif. 

2. Dispositif selon la revendication 1, caracterise en ce 
que les moyens de controle comprennent des moyens de 
verification de la coherence du contenu de la memoire 
volatile, des memo ires de donne e s e t de s memo i r e s de 
programmes de l 1 objet electronique portatif en fonction de la 
transition d' etats a effectuer. 

3. Dispositif selon l'une quelconque des revendications 1 
ou 2, caracterise en ce que les moyens de controle comportent 
des moyens d 1 autorisation et/ou interdiction des transitions 
d'etat. 

4. Dispositif selon l'une quelconque des revendications 1 
a 3, caracterise en ce que les moyens de controle 
comprennent : 

- une table (11) des transitions d ! 6tat possibles; 

- une table (12) des verifications a effectuer par 
transition d'etat possible; 

- un moteur de verification (9) exploitant lesdites 

tables . 
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5. Dispositif selon l'une quelconque des revendi cat ions 1 
a 4, caracterisS en ce qu'il comprend des moyens permettant 
de declencher des actions lors du traitement d'une demande de 
franchissement de transition d'un etat a un autre etat de 
l'objet Slectronique portatif. 

6. Dispositif selon l'une quelconque des revendi cat ions 1 
a 5, caracterise en ce que des actions, dites actions 
systematiques, sont declenchees lors du franchissement d'une 
transition ou du re jet du franchissement d'une transition. 

7. Dispositif selon l'une quelconque des revendi cat ions 1 
a 6, caracterise en ce que des actions, dites actions 
positives, sont declenchees lors du franchissement d'une 
transition. 

8. Dispositif selon l'une quelconque des revendications 1 
a 7, caracterise' en ce que des actions, dites actions 
negatives, sont declenchees lors du re jet de franchissement 
d'une transition. 

9. Dispositif selon l'une quelconque des revendications 1 
a 8, caracterise en ce que les moyens permettant de 
declencher des actions lors du traitement d'une demande de 
franchissement de transition d'un etat a un autre etat de 
l'objet electronique portatif, comprennent une table (13) 
d' actions exploitable par ledit moteur de verification (9) . 

10. Dispositif selon l'une quelconque des revendications 
1 a 9, caracterise en ce que des Stats supplementaires (dits 
Stats additifs) peuvent §tre ajoutes au sein de la memoire de 
donnSes . 
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11. Dispositif selon la revendication 10 , caracterise en 
ce que les moyens de controle de la transition d'un etat a un 
autre etat de l'objet electronique portatif comprennent en 
outre au moins : 

5 - une extension (16) de la table (11) des transitions 

d'etat possibles; 

- une extension (17) de la table (12) des verifications a 
effectuer par transition d'etat possible; 

et en ce que le moteur de verification (9) exploite 
10 lesdites extensions de tables (16, 17) . 

12. Dispositif selon I'une quelconque des revendications 
10 ou 11, caracteris6 en ce que les moyens permettant de 
declencher des actions lors du traitement d'une demande de 

15 f ranchissement de transition d'un etat a un autre etat de 
l'objet electronique portatif, comprennent au moins une 
extension (18) de la table (13) d' actions exploitable par le 
moteur de verification (9) . 

20 13. Dispositif selon l'une quelconque des revendications 

1 a 12, caracterise en ce que la demande de transition peut 
etre gen^ree par une action declenchee lors du f ranchissement 
ou du re jet du f ranchissement d'une transition. 

25 14. Objet electronique portatif, comportant une unite de 

traitement (2) , une memoire volatile (3) , des memoires de 
programmes (4) et des memoires de donnees (5) , caracterise en 
ce qu ! il comporte le dispositif de controle du cycle de vie 
de l'objet, selon l'une des revendications 1 a 13 . 

30 

15. Carte & puce, comportant une unite de traitement (2), 
une memoire volatile (3) , des memoires de programmes (4) et 
des memoires de donnees (5), caracterise en ce qu'elle 
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comporte le dispositif de controle du cycle de vie de la 
carte, selon l'une des revendications 1 a 13. 

16. Proc£de, destine a etre exploite par un dispositif de 
controle du cycle de vie d'un objet electronique portatif 
comprenant une unite de traitement (2) , une memoire volatile 
(3), des memoires de programmes (4) et des memoires de 
donnees (5), le contenu desdites memoires definissant une 
plurality d' etats qui correspondent respectivement a une 
configuration donnee de 1' objet, chacun desdits etats 
determinant les services offerts par ledit objet, 

caracterise en qu'il comporte une plurality d'etapes, 
lesdites Stapes etant dependantes du type des 6tats impliques 
dans la demande de f ranchissement d'6tat appliquee a 1' objet, 
le premier type d'etat correspondant aux etats predefinis 
15 dans la memoire de programmes (4), dits "etats de reference" 
et, le second type d'etat correspondant aux etats pouvant 
etre ajoutes dans la memoire de donnees (5), dits "6tats 
additif s" . 



17. Procede selon la revendication 16, pour lequel la 
demande de f ranchissement de transition appliquee a 1" objet 
est une demande de f ranchissement de transition d'un etat de 
reference vers un autre etat de reference, caracterise en que 
ledit procede comprend au moins : 

- une 6tape (51) de validation de 1 ' autorisation de 
ladite demande en analysant la table (11) des transitions 
possibles; 

- une etape (52) devaluation des verifications associee 
a la transition demandee en analysant une table (12) des 

30 verifications; 

- une etape (57) de modification de 1 ' etat courant de 

l 1 objet si et seulement si : 

- la transition demandee est autoris^e (51) 
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- et, si les verifications de la configuration de 
l'objet sont satisfaites (54). 

18. Precede selon l'une quelconque de la revendication 
5 17, caracterise en ce qu'il comprend en outre une etape (53) 
d ! execution d 1 actions syst^matiques en analysant 1 ' entree de 
la table (13) d' actions correspondant a la transition 
demandee . 

10 19. Procede selon l'une quelconque des revendications 17 

ou 18, caracterise en ce qu'il comprend en outre une etape 
(56) d 1 execution d 1 actions positives en analysant 1 ' entrle de 
la table (13) d' actions correspondant a la transition 
demandee dans le cas ou la transition demandee est autorisee 

15 (51) et si les verifications associees a la transition 
demandee sont satisfaites (54) . 

20. Procede selon l'une quelconque des revendications 17 
a 19, caracterise en ce qu'il comprend en outre une etape 
2 0 (55) d 1 execution d' actions negatives en analysant 1 • entree de 
la table (13) d' actions correspondant a la transition 
demandee dans le cas ou les verifications associees a la 
transition demandee ne sont pas satisfaites (54) . 

25 21 . Procede selon la revendication 16 , pour lequel la 

demande de f ranchissement de transition appliquee a l ! objet 
est une demande de f ranchissement de transition d'un €tat 
additif vers un autre etat additif, caracterise en ce qu'il 
comprend au moins : 

30 - une etape (511) de validation de 1 1 autorisation de 

ladite demande en analysant une extension (16) de la table 
(11) des transitions possibles; 
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- une etape (512) d 1 evaluation des verifications associ£e 
a la transition demandee en analysant une extension (17) de 
la table (12) des verifications; 

- une etape (517) de modification de l'£tat courant de 
l'objet si et seulement si : 

- la transition demandee est autorisee (511) 

- et, si les verifications de la configuration de 
l'objet sont satisfaites (514). 

22. Procide selon la revendication 21, caracteris6 en ce 
qu'il comprend en outre une etape (513) d'execution d' actions 
systematiques en analysant 1' entree d'une extension (18) de 
la table (13) d 1 actions correspondant a la transition 
demandee . 

23. Procede selon l'une quelconque des revendications 21 
ou 22, caract^rise en ce qu'il comprend en outre une etape 
(516) d' execution d' actions positives en analysant 1' entree 
de l- 1 extension (18) de la table (13) d'actions correspondant 
a la transition demandee si : 

- la transition demandee est autorisee (511) 

- et, si les verifications associees a la transition 
demandee sont satisfaites (514) . 

24. Procede selon l'une quelconque des revendications 22 
a 23, caracterise en ce qu'il comprend en outre une etape 

(515) d'execution d'actions negatives en analysant 1 ' entree 
d'une extension (18) de la table (13) d'actions correspondant 
a la transition demandee dans le cas ou les verifications 
associees a la transition demandee ne sont pas satisfaites 

(514) . 

25- Procede selon la revendication 16, pour lequel la 
demande de f ranchissement de transition appliquee a l'objet 



est une demande de f ranchissement de transition d'un etat de 
reference vers un etat additif, caract^rise en ce qu'il 
comprend au moins : 

- une etape (528) de validation de 1 1 autorisation de 
d'une transition dudit etat de reference vers un etat additif 
en analysant la table (11) des transitions possibles; 

_ une etape (521) de validation de 1 1 autorisation de 
d'une transition dudit etat de reference vers ledit etat 
additif en analysant une extension (16) de la table (11) des 
transitions possibles; 

une troisieme etape (522) devaluation des 
verifications associee a la transition demandee en analysant 
une extension (17) d'une table (12) des verifications; 

- une etape (527) de modification de 1'etat courant de 
l'objet si et seulement si : 

- la transition demandee est autoris^e (528 , 521) 

- et, si les verifications de la configuration de 
l'objet sont satisfaites (524). 

26. Procede selon la revendication 25, caracterise en ce 
qu'il comprend en outre une etape (523) d 1 execution d 1 actions 
systematiques en analysant 1 1 entree d'une extension (18) de 
la table (13) d' actions correspondant a la transition 
demandee . 

27. Procede selon l'une quelconque des revendications 25 
ou 26, caracterise en ce qu'il comprend en outre une £tape 
(526) d'ex€cution d'actions positives en analysant 1 'entree 
d'une extension (18) de la table (13) d'actions correspondant 
a la transition demandee si : 

- la transition demandee est autorisee (528, 521) 

- et, si les verifications associees a la transition 
demandee sont satisfaites (524) . 



28. Procede selon l'une quelconque des revendi cat ions 25 
a 27, caracteris^ en ce qu'il comprend en outre une 6tape 

(525) d 1 execution d 1 actions negatives en analysant 1 1 entree 
d'une extension (18) de la table (13) d' actions correspondant 
a la transition demandee dans le cas ou les verifications 
associees a la transition demandee ne sont pas satisfaites 

(524) . 

29. Proc6d6 selon l'une quelconque des revendications 16 
a 28, caracterise en ce que ledit procedS n'autorise pas le 
franchissement d'une transition d'etat, d'un #tat additif 
vers un 6tat de reference. 



^^pille rectifies 
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REVENDICATIONS 



1. Dispositif de controle du cycle de vie d'un objet 
electronique portatif, le cycle de vie etant determine par 
une succession de transitions d' etats, lesdits etats 
determinant les services of ferts par 1 1 objet, ledit objet 
comprenant une unite de traitement (2), une memoire volatile 
(3), des memoires de programmes (4) et des memoires de 
donnees (5), chacune de ces memoires (3, 4, 5) presentant un 
contenu definissant une pluralite de configurations, 

caracterise en ce qu f il comporte des moyens de controle 
de la transition d'un premier etat a un second etat de 
1' objet electronique portatif. 

2. Dispositif selon la revendications 1, caracterise en 
ce que les moyens de controle comportent des moyens 
d' autorisation et/ou interdiction de transitions d'etat. 

3. Dispositif selon l'une quelconque des revendications 1 
ou 2, caracterise en ce que les moyens de controle 
comprennent des moyens de verification du contenu de la 
memoire volatile (3), des memoires de donnees (5) et des 
memoires de programmes (4) de I'objet electronique portatif 
en fonction de la transition d 1 etats a effectuer. 

4. Dispositif selon l'une quelconque des revendications 1 
a 3, caracterise en ce que les moyens de controle 
comprennent : 

- une table (11) des transitions d'etat possibles; 

- une table (12) des verifications a effectuer par 
transition d'etat possible; 

- un moteur de verification (9) exploitant lesdites 

tables . 
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fejiIHe rectifies 



5. Dispositif selon l'une quelconque des revendications 1 
a 4, caracterise en ce que les moyens de controle comprennent 
en outre des moyens permettant de declencher des actions lors 
du traitement d'une demande de f ranchissement de transition 
d'un premier etat a un second etat de l'objet electronique 
portatif. 

6. Dispositif selon la revendication 5, caracterise en ce 
que les moyens permettant de declencher des actions lors du 
traitement d'une demande de f ranchissement de transition d'un 
premier etat a un second etat de l'objet electronique 
portatif, comprennent une table (13) d' actions exploitable 
par ledit moteur de verification (9) . 

7. Dispositif selon l'une quelconque des revendications 1 
a 6, caracterise en ce que les moyens de controle de la 
transition d'un premier etat a un second etat de l'objet 
electronique portatif comprennent en outre : 

- une extension (16) de la table (11) des transitions 

d'etat possibles; 

- une extension (17) de la table (12) des verifications a 
effectuer par transition d'etat possible; 

et en ce que le moteur de verification (9) exploite 
lesdites extensions de tables (16, 17) . 

8. Dispositif selon l'une quelconque des revendications 5 
a 7, caracterise en ce que les moyens permettant de 
declencher des actions lors du traitement d'une demande de 
f ranchissement de transition d'un premier etat a un second 
etat de l'objet electronique portatif, comprennent en outre 
une extension (18) de la table (13) d' actions exploitable par 
le moteur de verification (9) . 



feMfce rectifiee. 
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9. Ob jet electronique portatif, comportant une unite de 
traitement (2),. une memoire volatile (3), des memoires de 
programmes (4) et des memoires de donnees (5), caracterise en 
ce qu'il comporte le dispositif de controle du cycle de vie 
de l'objet, selon l'une des revendications 1 a 8. 

10. Carte a puce, comportant une unite de traitement (2), 
une memoire volatile (3), des memoires de programmes (4) et 
des memoires de donnees (5), caracterise en ce qu'elle 
comporte le dispositif de contrdle du cycle de vie de la 
carte, selon l'une des revendications 1 a 8. 

11. Procede de controle du cycle de vie d'un objet 
electronique portatif, le cycle de vie etant determine par 
une succession de transitions d'etats, lesdits etats 
determinant les services offerts par l'objet, ledit objet 
comprenant une unite de traitement (2), une memoire volatile 
(3), des memoires de programmes (4) et des memoires de 
donnees (5), chacune de ces memoires (3, 4, 5) presentant un 
contenu definissant une pluralite de configurations, 

ledit procede etant mis en oeuvre, au sein de l'objet, a 
la suite d'une demande de transition d'etats, 
caracterise en qu'il comprend : 

- une etape (51, 511, 528, 521) de validation de 
1 ' autorisation de ladite demande; 

- une etape (52, 512, 522) devaluation des verifications 
associee a la transition demandee; 

- une etape (57, 517, 527) de modification de 1 ' etat 
courant de l'objet si et seulement si la transition demandee 
est autorisee (51, 511, 528, 521) et, si les verifications de 
la configuration de l'objet sont satisfaites (54, 514, 524). 



12. Procede selon la revendication 11, caracterise en ce 
qu'il comprend en outre une etape (53, 513, 523) d' execution 
d 1 actions systematiques . 

13. Procede selon l'une quelconque des revendications 11 
ou 12 , caracterise en ce qu'il comprend en outre une etape 
(56, 516, 526) d' execution d f actions positives dans le cas ou 
la transition demandee est autorisee (51, 511, 528, 521) et 
si les verifications associees a la transition demandee sont 
satisfaites (54, 514, 524). 

14. Procede selon l'une quelconque des revendications 11 
a 13, caracterise en ce qu'il comprend en outre une etape 
(55, 515, 525) d' execution d' actions negatives dans le cas oil 
les verifications associees a la transition demandee ne sont 
pas satisfaites (54, 514, 524). 

15. Procede selon l'une quelconque des revendications 11 
a 14, mis en oeuvre au sein de l'objet, a la suite d'une 
demande de transition d'un premier etat de reference vers un 
second etat de reference, caracterise en qu'il comprend : 

- une etape (51) de validation de 1 ' autorisation de 
ladite demande consistant a analyser la table (11) des 
transitions possibles; 

- une etape (52) d'evaluation des verifications associee 
a la transition demandee consistant a exploiter une entree 
(30) d'une table (12) des verifications; 

- une etape (57) de modification de l'etat courant de 
l'objet si et seulement si la transition demandee est 
autorisee (51) et, si les verifications de la configuration 
de l'objet sont satisfaites (54). 
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16. Procede selon la revendication 15, caracterise en ce 
qu'il comprend en outre une etape (53) d' execution d' actions 
systematiques consistant a exploiter une entree (400, 401, 

5 404), correspondant a la transition demandee, d'une table 
(13) d'actions. 

17. Procede selon l'une quelconque des revendications 15 
ou 16 , caracterise en ce qu'il comprend en outre une etape 

10 (56) d' execution d'actions positives consistant a exploiter 
une entree (400, 402, 405), correspondant a la transition 
demandee, d'une table (13) d'actions, dans le cas ou la 
transition demandee . est autorisee (51) et si les 
verifications associees a la transition demandee sont 

15 satisfaites (54) . 

18. Procede selon l'une quelconque des revendications 15 
a 17, caracterise en ce qu'il comprend en outre une etape 
(55) d' execution d'actions negatives consistant a exploiter 

20 une entree (400, 403, 406), correspondant a la transition 
demandee, de la table (13) d'actions, dans le cas ou les 
verifications associees a la transition demandee ne sont pas 
satisfaites (54) . 

25 19. Procede selon l'une quelconque des revendications 11 

a 14, ledit procede etant mis en oeuvre au sein de l'objet, a 
la suite d'une demande de transition d'un premier etat 
additif vers un second etat additif, caracterise en ce qu'il 
comprend : 

30 - une etape (511) de validation de 1 ' autorisation de 

ladite demande consistant a analyser une extension (16) de la 
table (11) des transitions possibles; 

- une etape (512) devaluation des verifications associee 
a la transition demandee consistant a exploiter une entree 

35 (33) d'une extension (17) de la table (12) des verifications; 
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- une etape (517) de modification de l'etat courant de 
l'objet si et seulement si la transition demandee est 
autorisee (511) et, si les verifications de la configuration 
de l'objet sont satisfaites (514). 

20. Procede selon la revendication 19, caracterise en ce 
qu'il comprend en outre une etape (513) d 1 execution d 1 actions 
systematiques en analysant une entree (407, 408, 411), 
correspondant a la transition demandee, d'une extension (18) 
d'une table (13) d'actions . 

21. Procede selon l'une quelconque des revendications 19 
ou 20, caracterise en ce qu'il comprend en outre une etape 
(516) d' execution d'actions positives en analysant une entree 
(407, 409, 412), correspondant a la transition demandee, 
d'une extension (18) d'une table (13) d'actions demandee si : 

- la transition demandee est autorisee (511) 

- et, si les verifications associees a la transition 
demandee sont satisfaites (514) . 

22. Procede selon I'une quelconque des revendications 19 
a 21, caracterise en ce qu'il comprend en outre une etape 
(515) d' execution d'actions negatives en analysant une entree 
(407, 410, 413), correspondant a la transition demandee, 
d'une extension (18) d'une table (13) d'actions dans le cas 
ou les verifications associees a la transition demandee ne 
sont pas satisfaites (514) . 

23. Procede selon l'une quelconque des revendications 11 
a 14, ledit procede etant mis en oeuvre, au sein de l'objet, 
a la suite d'une demande de transition d'un etat de reference 
vers un etat additif, caracterise en ce qu'il comprend : 

- une etape (528) de validation de 1 ' autorisation de 
d'une transition dudit etat de reference vers un etat additif 
en analysant la table (11) des transitions . possibles ; 



- une etape (521) de validation de 1 1 autorisation de 
d'une transition dudit etat de reference vers ledit etat 
additif en exploitant une extension (16) d'une table (11) des 
transitions possibles; 

- une etape (522) devaluation des verifications associee 
a la transition demandee en exploitant une entree (33) d'une 
extension (17) d'une table (12) des verifications; 

- une etape (527) de modification de l'etat courant de 
l'objet si et seulement si la transition demandee est 
autorisee (528, 521) et, si les verifications de la 
configuration de l'objet sont satisfaites (524). 

24. Procede selon la revendication 23, caracterise en ce 
qu'il comprend en outre une etape (523) d' execution d' actions 
systematiques en exploitant une entree (407, 408, 411), 
correspondant a la transition demandee, d'une extension (18) 
d'une table (13) d' actions. 

25. Procede selon l'une quelconque des revendications 23 
ou 24, caracterise en ce qu'il comprend en outre une etape 
(526) d' execution d' actions positives en exploitant une 
entree (407, 409, 412), correspondant a la transition 
demandee, d'une extension (18) d'une table (13) d'actions si: 

- la transition demandee est autorisee (528, 521) 

- et, si les verifications associees a la transition 
demandee sont satisfaites (524) . 

26. Procede selon l'une quelconque des revendications 23 
a 25, caracterise en ce qu'il comprend en outre une etape 
(525) d' execution d'actions negatives en exploitant une 
entree (407, 410, 413), correspondant a la transition 
demandee, d'une extension (18) d'une table (13) d'actions 
dans le cas ou les verifications associees a la transition 
demandee ne sont pas satisfaites (524). 
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27. Procede selon l'une quelconque des revendications 11 
a 26, caracterise en ce que ledit procede n'autorise pas le 
f ranchissement d'une transition d'etat, d'un etat additif 
vers un etat de reference. 
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